S3からBigQueryへの転送をリトライしてハマった部分を調査及び回避手順を検討してみた

BigQuery Data Transfer Service for Amazon S3にて転送設定を組んだものの、正常に取り込まれるケースとそうでないケースが混在する状態に陥っていました。公式ドキュメントにある転送設定の注意書きを交えつつ、取り込まれたかどうかの見極めと、対策の手続きについて書いてみました。

転送設定の事前注意

S3URIの指定ミス、及びポップアップが無効になっているとそもそも転送されません。

転送構成で共通の接頭辞を持つすべてのファイルを読み込むはずであった場合は、Amazon S3 URI の末尾にワイルドカードを使用します。たとえば、s3://my-bucket/my-folder/ 内のすべてのファイルを読み込むには、転送構成での Amazon S3 URI は s3://my-bucket/my-folder/ とするだけでなく、s3://my-bucket/my-folder/* として設定する必要があります。

データ転送を管理するために BigQuery Data Transfer Service 権限を付与します。BigQuery ウェブ UI を使用して転送を作成する場合は、ブラウザに console.cloud.google.com からのポップアップが表示されることを許可して権限を表示する必要があります。詳細については、BigQuery Data Transfer Service の有効化をご覧ください。

また、これらの条件を満たしていたとしても、定期的に実行したい場合は24時間のインターバルが必要になります。

定期的な転送の最小間隔は 24 時間です。デフォルトの定期的な転送間隔は 24 時間です。

オンデマンド転送の再実行は転送対象になるファイルの条件を確認する

オンデマンドによる転送を行った後、前回が正常及びエラーかを問わず再実行を行うと以下のようなログを目にすることがあります。

Starting transfer from Amazon S3 for files modified between … and … (exclusive).

例えば、再実行時刻が 2021年8月25日 17:56:55 JST で、ログには 2021-08-24T22:56:48-07:00 and 2021-08-25T01:46:57-07:00 間に編集されたファイルの転送を開始した、という状態。

ログの時刻をどう見るべきか迷うところですが、JSTの表記がない点で恐らくは基準となるUTC。UTCでの実行時刻はこの場合 2021年8月25日 8:56:55 UTC です。ログの -07:00 時間差を差っ引くと、実行時刻との差が10分程度となっています。これはS3バケットに入ったファイルが転送対象になるまで10分程かかるところを考慮した可能性があります。

Amazon S3 からデータを転送する際、バケットにファイルが追加されてまもない場合は特に、一部のデータが BigQuery に転送されない可能性があります。ファイルがS3バケットに追加されてから BigQuery Data Transfer Service で使用できるようになるまでに約 10 分かかります。

ポイントは、S3バケット追加後10分経ってないファイルを初回転送で対象にして且つエラーで取り込まれなかった場合。この場合、即再実行を検討しても更新タイムスタンプが実行時刻より10分以上前のファイルを対象とする可能性があります。試しに何度か再実行を試みたものの、いずれも対象外となりました。

転送を一回だけ行う場合には無縁なものでしょうが、BigQuery側のテーブル設計に誤りがあって転送失敗になり、処置としてテーブル修正後の再実行とした場合に遭遇するでしょう。時間を置かずに転送を試したい場合は、転送設定を削除して作り直しとなります。

オンデマンドでの転送が意図通りに完了しているかを見極める

概要に「転送実行が正常に完了しました。」とあっても当てにならないため、ログをみます。ログは最後から順に最初へ辿ると手間が省けます。

まずはおそらく最後に出力されているSummaryで succeeded を確認します。

Summary: succeeded 1 jobs, failed 0 jobs.

転送対象外となっていた場合には succeeded と failed の両方に含まれません。

Summary: succeeded 0 jobs, failed 0 jobs.

次に、以下のログが出ていた場合で該当のS3バケットにファイルがあるなら、期間を疑います。

No files found matching s3://…

そして、より遡ってJobの実行結果が存在するかどうかを確認しましょう。転送が行われた場合には成否と転送したレコード数、及びエラー数が表示されます。

Job bqts_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (table xxxxx) completed successfully. Number of records: 1714822, with errors: 0.

No files found matching s3://.. のログがある場合は Starting transfer from Amazon S3 for files modified のログまでたどります。後は先程あげたとおりです。

あとがき

オンデマンドでの転送で制約に遭遇した際に定期的な転送での最小間隔とも異なることを確認しているため、オンデマンドでの検証とスケジュールでの検証は別途必要になるでしょう。

初めて転送を試みる場合にはとてもはまりやすい場所だと思いますが、挙動が分かれば後は想定どおりに動くまで兎に角繰り返すだけです。プロジェクト選択が時折解除されてリダイレクトかかることもありますが、挫けずトライしましょう。